Companies that use Business Process Management (BPM) and/or other modeling tools oftentimes produce a lot of information, e.g., in the form of various models. These models may be used in many scenarios, not only as a description of the most important processes, but also potentially in implementing processes, controlling the daily business in the company, etc. Over the years, modeled structures have become “fillable” with many different types of detailed information, e.g., on times and other indicators, and now quite often are much more than simple pictures. The ability to provide an ever-growing number of details has concomitantly enabled the target group of users of the models to grow. Indeed, various roles in a company frequently involve information on modeled processes, even without the express knowledge that the associated data is based on models. Consider, for example, that for published information, reports, and/or the like, model content may be distributed through the whole company and/or to external consumers.
Models (e.g., process models such as, for example, event-driven process chain or EPC models, organizational charts, etc.) frequently include objects and relations between these objects. It might happen that objects occur in various models and that they have many relations to other objects that also occur in various models. Because of such relations or occurrences in the same models, the existence of common related objects, etc., indirectly related objects sometimes may belong in the same context for an evaluation. Such indirect relations are also sometimes called implicit relations.
Complex structures such as these frequently are the basis for business questions, e.g., for key performance indicator (KPI) calculations on costs and resources of a process, reports like role descriptions, and/or other forms of ad hoc analysis. An example for such business questions could be phrased in a very simple form, such as: “Which functions are executed by Person A?” There are, however, many possible results. For instance, Person A could be related to functions via certain relations such as, for example: Person A executes the function; Person A contributes to the function; Person A is responsible for the function; Person A must be informed about the function; and so on.
But the person could also be responsible for a process, with the functions being in the sub-process. This might be relevant in some scenarios and could be an example of an implicit relation. Another implicit relation could be that the person has certain roles, and the roles are related to functions. There are other possibilities, as well, but without exact knowledge of all variants, it oftentimes is difficult if not impossible for a normal business user to evaluate such structures (e.g., without the help of an expert). Indeed, the number of different methodic information forms (e.g., relation type, model types, symbols, and so on) may make it difficult, to define the correct set of information that is needed to make a correct analysis.
Because strategic decisions in companies are often based on such analyses, it oftentimes is desirable to have the right data and the complete data. To evaluate such a complexity today, experts with programming knowledge frequently are consulted, e.g., to define the various output formats and to evaluate the data to retrieve all necessary information. The approach of defining the right data could be described as “additive” approach. Today's approaches are generally “additive” in nature: Step-by-step, the right set of data is defined by a user. Depending on the user's knowledge of the methodology, this may take several iterations or—in the worst case—might be impossible for an end user.
Some approaches involve the formulation of queries on modeled structures. In such cases, the queries quite often are based on a functional specification that is then implemented using a scripting language such as, for example, JavaScript, SQL statements, XML, etc. Unfortunately, however, query definition is generally limited by the designer's knowledge of the methodology. Graphical query definition sometimes is possible. But even in this case, there also generally needs to be a complex mapping between the graphical representation and the methodology that is used, and a change in the methodology needs to be reflected in the mapping for the definition to remain in working order. As a result, existing technologies generally are limited by the amount of knowledge a query definer has and, even when a person is an “expert,” the knowledge might not be sufficient for a given task. Indeed, many commercially available products produce output for business users, but experts typically are needed to retrieve the necessary data, since the output is driven by complex scripting languages, SQL statements, etc.
Reporting based on scripting languages, for example, generally will involve a change to the underlying script(s) if the modeling conventions change. In such cases, it typically is not possible for an average business user to change the report structure in a way that guarantees that the new conventions are directly adapted. Instead, each change typically involves programming effort and costs. And where editors are used, an expert's knowledge oftentimes is needed to identify those parts of the methodology that need to be adapted. Moreover, if Business Intelligence (BI) tools are used, the modeled data oftentimes needs to be “translated” via SQL or XML. Changes in the data therefore will involve a new export from the modeling tool to the BI tool, and changes in the modeling conventions will, in turn, generally involve a change in the mapping format and involve at least some form of programming effort. In the case of a query editor, a certain format of building queries typically must be learned.
It is believed that current approaches do not guaranty a generic usage. For instance, depending on the topic, a certain evaluation may need to be defined, a certain set of the methodological information may need to be mapped to the evaluation approach, etc.
And with each change in the methodology or the modeling conventions on which the query is defined, the query may need to be adapted. There are even scenarios that will require the editor to be changed. The consistency of the results cannot always be guaranteed in such situations.
These changes can result in even more disadvantages. For example, it oftentimes is not possible for a user to differentiate if a change in the modeling or the modeling convention will require an adaptation to retrieve another result. There accordingly may be a large amount of wasted effort associated with answer the question as to whether it is necessary to react on a renaming of a type, a new symbol, a new maintained attribute, etc. As another example associated with the additive approach, the user may have to try to find out (e.g., by trial-and-error) what is missing, and the user may have to add the missing artifacts from the modeling to the query definition—even though it may not be possible to make a live evaluation of the data.
FIG. 1 helps to illustrate a problem with state of the art technology. The query only knows the pattern that follows the modeling restrictions from type A to type B. Using such a query, the result may only contain B1, which is an instance of type B. Object B1 will be found by the query, as only this pattern (shown in the middle path) is covered by the query. The objects B2 and B3, both of type B, will be missing in the result, although there is a possible path from A to these objects. In the best case, the user may recognize that B2 and/or B3 is/are missing. In this scenario, the user will have to change the query by adding the patterns to the query that will lead to B2 and B3. A common problem exists, however, because the user probably will not know about B2 and B3 in complex databases. That is, the user may not see that they exist, the user may not see that there are “relations” that can connect A with B2 and B3, etc. Such a specific evaluation may not be complete, or the complexity of modeling may need to be reduced to retrieve correct results. But doing so may cause a large amount of redundant modeling information.
Thus, it will be appreciated that there is a need in the art for a path finding technique, where a potentially non-technical end-user can define the whole data set that is needed by using a normal model design methodology and where the user is presented with a repeatable analysis and an output.
One aspect of certain example embodiments relates to a new way of defining relevant data for analysis and reporting for modeled processes and process-related data. Similar to a car navigation system, in certain example embodiments, all possible “routes” between a source object and a target object are identified, and the user is able to select one or more routes of potential interest. The user does not, however, have to leave the “modeling environment” and can use well-known terms for the definition.
Another aspect of certain example embodiments relates to following and tracing paths of interest between two given objects, even when there are many complex paths therebetween, e.g., by enabling a user to potentially iteratively exclude possible paths without a detailed knowledge of the underlying model(s), system architectures, etc.
Another aspect of certain example embodiments relates to an “excluding” or “subtractive” approach for limiting the paths from a source object to a target object, e.g., after a complete map of such is developed.
Still another aspect of certain example embodiments relates to the definition of limiting criteria for excluding possible paths from a net of all possible paths. Such limiting criteria may include, for example, specification of maximum path length, indications of required stopovers, use of existing filtering technologies, etc., to “fade out” irrelevant paths and/or paths that are not of interest to a user.
In certain example embodiments, a path finding method for use with a model comprising a plurality of objects is provided. Input specifying a source object and a target object is received, from a user and via a user interface. A net representing at least all methodic-level objects in the model being a step of at least one path between the source object and the target object, and all relationships between these methodic-level objects in the model, is developed. A list of paths, through the net, from the source object to the target object, is compiled, with each said path having a path length associated therewith. Individual ones of said paths that fail to meet one or more user-specified limitations are excluded from the list of paths and in connection with at least one processor. The one or more user-specified limitations includes a maximum path length, at least one stopover item that must be present between the source and target objects, and/or at least one attribute-based filter. Following said excluding, the list of paths is displayed to the user in text-based and/or graphical form.
In certain example embodiments, a computer system is provided. Processing resources include at least one processor and a memory, and a display also is provided. A data source stores a model comprising a plurality of objects. A user interface is configured to receive input specifying a source object and a target object in the model. The processing resources are controllable to at least: develop a net representing at least all methodic-level objects in the model between the source and target objects, and all relationships between these methodic-level objects in the model; compile a list of paths, through the net, from the source object to the target object, each said path having a path length associated therewith; exclude, from the list of paths, individual ones of said paths that fail to meet one or more user-specified limitations, the one or more user-specified limitations including a maximum path length, at least one stopover item that must be present between the source and target objects, and/or at least one attribute-based filter; and following said excluding, display the list of paths to the user in text-based and/or graphical form on the display.
In certain example embodiments, there is provided a non-transitory computer readable storage medium tangibly storing instructions that, when executed by at least one processor of a system, perform a method as described herein.
These aspects, features, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.